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Cairns 2-17, 26-41, 50, 51, 60-70, 77-87, and 98 were rejected under §102 as being 
anticipated by the INSS article, and under §103, as being obvious in view of the INSS 
article- Gaims 99-162 have been added. 

Anticipation under §102: 

The refection stated that the fact that INSS maintains offer history data to determine if 
art optimal agreement has been reached or to suggest a Pare to-Optimal agreement for 
bo$h parties is indicative of the fact that INSS itself analyzes and understands the 
negotiation terms. 

Appttdants respectfully disagree. INSS is not a negotiations system, it is not analyzing 
terms during iterative processing to understand the purpose of the terms, it does not 
identify which terms relate to which party, it does not recognize changes in terms, and 
it does not recognize at least one party as a deciding entity. 

The INSS system does not do any analysis to understand the purpose of terms to 
generate a Pareto-optimal agreement for both parties, nor does it identify which terms 
and inputs relate to which party and are significant to the Pareto-optimal analysis. The 
INSS article makes clear in discussing how to "Describe a new negotiation case", that all 
the terms and values for the mock negotiations are provided to the INSS system b£ 
whoevter builds the case before anv mock negotiation beg ins. As will be seen, this 
eliminates the need for any analysis of terms to understand their purpose, whether to 
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simulate a negotiation, to generate a Pareto-optimal agreement or to identify which 
terms and inputs are significant to a Pareto-optimal analysis. 

In fact the INSS article makes it quite clear that the values assigned to terms (called 
options (values) and issues (similar to terms) in INSS) are irrelevant to its Pareto 
''analysis"- While sounding complex, a Pareto-optimal agreement is nothing more than 
one which could not be improved for one party without making it worse for the other* 
Historically, negotiation support systems (NSS) might have attempted to perform an 
objective analysis of the values of the terms in an agreement to determine this. That is, 
they might have tried to find an agreement say, with better price terms for both parties 
than the one they agreed upon. This could be useful if price is the most important 
factor for both parties. However, it is often the case that objective measures such as 
price Or delivery times are not as important to the parties as other, more subjective 
factors. 

Thus some modern NSS systems typically do not attempt objective analysis of terms at 
all. Instead, they rely solely, as INSS expressly does (as will be seen below), on 
subjective ratings which the users supply. Thus it is irrelevant which agreement might 
"objectively" be better or optimal for both parties. It is also irrelevant which terms are 
significant for Pareto optimality for two reasons. First INSS doesn't analyze the terms 
(issues and options in INSS), for Pareto analysis — it only looks at ratings* Second, the 
users of INSS are asked to rate all the terms and combinations and values — thus no one 
term (issue) or value (option) is more significant than another — all get ratings. As will 
be seen, this makes the computation of Pareto-optimality a simple arithmetic problem 
of comparing ratings that does not require analyzing terms (issues and options) at all, 
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To see this, it helps to understand how INSS works and its terminology. At 1NSS page 6, 

uridef the heading "Describe a new negotiation case", the article states: 

"You clan request that a new negotiation case be set up for you by submitting this form. 
Specify the issues 

At a minimum you must specify the names of the issues that will be negotiated, and the 
options that each issu e may take . For example: 

"Annual salary" - "50,000", "70,000" or "100,000" dollar 
"Vacation" - 2, 4 or 6 weeks/' [Underlining emphasis added.] 

In the glossary of the INSS article on page 19, an issue is defined as: 

"A topic of discussion that is of particular interest in a negotiation. Each issue has a 
range of alternatives or options, one of which must ultimately be agreed upon by the 
negotiators in order to achieve i compromise," 

And at Page 20, an option is defined as: 

"One of the alternative values that an is§yg_can take. For example, the issue 'Tolerable 
product failure rate" may have the options "3%", "5%" and "10%". 

in bther words, an issue is similar to a term in a real negotiation. However, because this 
is a simulation using a simulation model or case, as seen here, all the possible values for 
an issue (term) must be defined in advance. In this instance, these values are supplied 
as what INSS calls "options". As noted above, the article says that to create a new case 
you myist, at a minimum, specify the names of the issues that will be negotiated, and the 
options;that each issue may take . 
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137. The method of Claim 123, wherein the step of using formatting choices further 
comprises the step of configuring the database to direct attention to changes by linking 
a uniform resource locator to at least one subset of the changed terms- 
Kindly add Claim 1 38 as follows: 

138. The method of Claim 123, wherein the step of using formatting choices further 
comprises the step of configuring the database to direct attention to changes by 
transmitting a notification to the user, the notification referring to the changed terms. 

Kindly add Claim 1 39 as follows: 

139. The method of Claim 123, wherein the step of using formatting choices further 
comprises the step of configuring the database to direct attention to changes by sending 
an electronic mail message including the changed terms* 

Kindly add Claim 140 as follows: 

140. the method of Claim 123, wherein the step of using formatting choices further 
comprises the step of configuring the database to direct attention to changes by sending 
ah electronic mail message referring to the changed terms. 
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Again, on Page 8, under the headings "Using INSS: An Example", and "Negotiations 
between Maki and Suny", the article describes a sample negotiation case which has 
been set up by the article's authors to show how to use INSS; 

"There are only two issues in this simple negotiation: the price o£ the aircraft and the 
terms of the warranty. It has been established that the normal price of this aircraft is in 
thei range of $300,000 to $320,000. The sensible increase is of $10,000. Thus, the price 
options, are $300,000, $310,000, and $320,000. In this industry there are four types of 
warranty typically available. The options are: no warranty, a 6 month, one year, and a 2 
year warranty. 

Both negotiators analyze the two issues and their associated options in terms of their 
relevance to their respective organizations and mpve to the pre-ne^otiation^ phase, 
[Underfilling emphasis added.] 



As the rest of this example shows, all the possible terms and all the possible values 
(issues and options in INSS terminology) of this negotiation are already in the model as 
some combination of the two issues (terms) with their respective options (values). 



In this : aircraft example, from the INSS article there would be 12 possible sets of issues 
and option** that would make up an aircraft model: 
AIRCRAFT MODEL; 



Package No. 


Issue 1 


Issue 2 


1 


$300,000 


0 


2 


$300,000 


6mos. 


3 


$300,000 


lyr 


4 


$300,000 


2yt 


5 


$310,000 


0 


6 


$310,000 


6mos. 


7 


$310,000 


1 yr 


8 


$310,000 


2yr 


9 


$320,000 


0 


10 


$320,000 


6mos. 


11 


$320,000 


1 yr 


12 


$320,000 


lyr 



* Ratings marked with an asterisk are hypothetical and not taken 



Maki's rating 

30* 

15* 

20* 

0* 

50* 

40* 

30* 

25* 

100 

75 

90 

60 



Suny's rating 

70* 

80* 

100* 

90* 

40* 

50* 

60* 

30* 

0* 

20* 

15* 

10* 

from the INSS article. 
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Again, in the glossary at Page 20, a package is defined as 

"A particular combination of options that has been selected across all the issues- For 



Price 


3000$ 


Payment 


Upon Delivery 


Failure rate 


5% 



Thus it can be seen that for each case used for the mock negotiations using the INSS 
simulation system, «11 variabl e s are known ahead of time and inserted into the case 
or tnofel by issue name and option v alue prior to anv mock negotiation : For the 
aircraft model, issue (term) one can have three options (values)-$300,000, $310,000 or 
$320,000, Tssue (term) 2 can have four options (values): 0, 6 months, 1 year or 2 years. 
The combination of three options (values) for issue 1 and four options (values) for issue 
2 results in 12 possible outcomes or packages, as seen above. They can be stored in the 
computer in a simple table similar to aircraft model shown above, or in similar 
arrangements in a file. Not only is there no disclosure of analysis by the INSS simulator 
to understand the purpose of the terms in the INSS article, there is no need or 
requirement for analysis to understand the purpose of the terms, or in the case of INSS, 
the issues, since all of their possible values (options) must already be known ahead of 
time by the simulator. 

In' the two examples cited in the TNSS article, it does not matter whether the name of 
issue 1 in case 1 is annual salary or as in the aircraft model, issue 1 is named price. What 
matters is that all the possible options or values for that issue number are specified 
ahead of time so the case can be built. The simulator neither knows nor cares that it is 
simulating a price negotiation as opposed to a salary negotiation. It does not analyze 
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terms or need to analyze them, during a mock negotiation, since they are predefined in 
the model as issues and options. All that is needed for the INSS simulator to operate is a 
setof pre-defined issues (terms) and options (values). 

This pre-definition is made even clearer on Page 17, where the INSS article states, under 

the heading "INSS FAQ (Frequently Asked Questions)", question no. 2: 

"2 I have requested a negotiation already. When can I start my negotiation? 
Your negotiation will be set up typically within 2-3 days. INSS will notify you yia e- 
mail, (s^dfying your negotiation name and user name), after which you can start your 
negotiation right away." 

The set up mentioned here refers back to Page 6, "Describe a new negotiation case, 
where the article states, "You can request that a new negotiation case be set up for you 
by; submitting this form." 



Neither of the players who use the INSS simulator for a mock negotiation supply the 
values (options) for the issues during their mock negotiations. These values have 
already been programmed into the case they are using bejore the mock negotiation 
begini In fact, unless one of the players is the one who requested that the case be 
constructed, neither of the players provides any input at all for "terms" (issues and 
their options) when he or she uses the INSS simulator. 

Page 8, for example, shows the aircraft case which has been set up by the authors to 
snow how to use INSS. In mis example, players "Maki" and "Suny" do not supply any 
of the options for issues 1 and 2. Since the "terms" (issues) and all possible values 
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(options) they can have are pre-programmed into a case before a mock negotiation can 
begin, mere is no need for, and no disclosure of any analysis done by the INSS 
simulator to understand the purpose of the terms (issues). Unlike applicants' invention, 
which analyzes terms during iterations of a negotiation to understand their purpose, it 
is irrelevant to the INSS simulator whether an "issue" is a price term or a warranty term 
or a salary term or a vacation term. INSS only deals with predefined options for named 
issues as these are stored in the model. 

Nor is there any disclosure of which terms (issues) relate to which party either before 
mock negotiation begins or during it. The values (options) for all the terms (issues) are 
supplied in advance bv the person who rreates the case, not by the parries during a 
mock negotiation. Since the person who builds the case need not be, and, more 
frequently, is not likely to be, either of the players who use the simulation case, it is 
dear Sat INSS also does not relate the terms (issues) to either player. In the aircraft case 
example, all the values (options) for all the terms (issues) have been supplied in 
advance by the authors, to show how to use INSS. There is no way in which INSS can 
relate any of the price ($320,000) or warranty (2 years) option values to player "Maki" 
or "Suhy", since neither player supplied them. Therefore, the rejection is also incorrect 
in stating that INSS must identify which terms (issues) relate to which party. 

What the players do supply are subjective ratings for the issues and values, but this, 
tw, is done before any mock negotiation can begin and in such a way that the simulator 
does he* provide any analysis, 
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At page 2, for example, under die heading "Using INSS" it states: 

There are three basic steps that are usually followed in any negotiation: 
Preparation for the negotiation, during which you study the situatioa identify the 
stakeholders, and develop a very clear understanding of the issues and interests 
involved. To help you do this step, INSS provides you with o detailed description of 
your negotiation case and then guides you through a sequence of pages on which you. 
tell theisystem how importan t each issue and altern ative is to you. This step ^ also 
cal led preference elititation. T h* information so obtained is used bv INSS in the next 
step to- fflve vou helpful feedback when constructing new offers or evaluating your, 
counterpart's offers ." [Underlining emphasis added] 

Again; this information about how each player rates the data is collected before a mock 
negotiation begins. At Pages 8 and 9, under the headings "Using INSS: An Example", 
and "Preparation", the article describes three types of ratings the players are asked to 
do: Issue rating, Option rating and package evaluation. 

In the example on page 8, of the aircraft case, the players Maki and Suny are first asked 
to irate the two issues. As the article notes : 

"Maki feels that price is far more important than warranty. Therefore, she assigns 70 
points to price and 30 to payment {sic— this presumably should have been warranty). 
Althotigh Maki does not know it, Suny feels that each issue is equally important and so 
Suny assigns 50 points to each/' 

On Page 9, under the heading Option rating, it is stated: 

"Afte* raring the issues, the o ptions in eac h issue must also be rated similarly. In die 
INSS system, for each issue at least one option must be assigned the maximum gating 
frir the issue and at least one option m ust be assigned a rating of 7;ero. [Emphasis 
added.] 

Note that this makes it even clearer that all the values (options) for the variables of a 
negotiation have been supplied in the case beforehand. What the players must do is rate 
me subjective importance to them of these issues (terms) and these actual values 
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(options). This is seen in the two tables showing player Maid's ratings for the issue 1 
and issue 2 options. 

At this point since all the possible values (options) for the only two issues in this case 
are! known, INSS also asks the players to evaluate packages— i.e. combinations of issues 
and options, such as those Applicants' attorney has listed above in the aircraft model. 
Package 9 in that table is the same as the first package listed in the INSS article on page 
9 for ivtaki— namely issue 1 having an option of $320,000 and issue 2 having an option 
value <if no warranty. Maki's rating of this package is 100. 

As INSS makes clear, the ratings by the players must be also be done before any mock 
negotiation can begin. 

The rejection of Applicants' claims suggests that INSS sends and receives terms along a 
communications path and that this is involved in the determination of Pareto- 
optimality . Applicants believe they have shown that in fact, neither party using INSS 
enters 1 issues, options or ratings during a mock negotiation. All possible issues and 
options were entered by the person who created the case beforehand. Thus INSS fiannot 
identify which issues and options relate to which party, since there is no way for a 
person creating a case to indicate this and no way for the players to do so either. 

INSSialso does not analyze terms to understand which are significant to a Pareto- 
optmtal outcome. By having the players rate the issues and options, the users or player* 
specify the data (their subjective ratings) to be used for determining a Pareto-optimal 
outcome— not the INSS system. Applicants respectfully submit that Pareto^optimality 
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sounds more complicated than it is. In this context it simply means that based on the 
subjective ratings the players provide ahead of time for each predefined package, there 
could be one or more packages that are better for both players (have a higher subjective 
ratangior both players without making either player worse off) than the one they may 
initially choose. 

Note that it is explicitly stated in INSS that this notion of "better" does not take into 
account any of the values supplied for the issues and options- It does not matter what 
the issue 1 and issue 2 values actually are for the INSS system in the aircraft model 
example cited. All that matters for a Pareto-optimal result is that both players may have 
subjectively rated one or more packages as better than a package they have agreed 
upon. 

This is made clear at Page 12, under the heading "Post-Settlement": 
"Efficient packages 

In some negotiations it may happen that the parties reach an agreement but there is (sic) 
one of more packages which are better than the accepted offer for both sides. Note that 
befter is measured with the parties utility functions . Thus, there may be a pfr<toge for 
which the two rating s are higher than the package that has been accepted. 

INSS has a post-settlement stage, during which it uses the preference information 
provided by each user to determine whether it is possible to construct packages that are 
better for the two parties**/' 
Utility function is defined in the glossary as: 

"A utility function is a subjective measur ement that expresses the relative value of 
different package Isicl by using a numerical scale. The numerical scale used is arbitrary. 
It typically ranges either from 0 to 1 or from 1 to 100. The minimum number expresses 
the least desirable and least preferred package. The highest number represents the most 
desirable and preferred package. " [Underlining emphasis added] 

In other words, the utility function INSS uses is simply the subjective ratings the players 
provide for the pre-defined packages. 
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In the aircraft model example above, if the parties had agreed upon Package 12 during 
the mock negotiation, for which their subjective ratings are 60 and 10 respectively, it can 
be seen that Package 10 would be Pareto-optimally "better" for both of them because 
eadh of them has subjectively rated Package 10 higher than Package 12. As mentioned 
above, these ratings are the player's subjective views of the importance of the issues 
(terms) and options (values). 



Thus, it is not necessary, nor does INSS disclose or render obvious a need to understand 
the purpose of terms (issues) or values (options) in order to determine a Pareto-optimal 
package. It is done solely on the basis of subjective ratings supplied in advance for 
packages defined in advance. As described at Page 12, the determination of such an 
optimal package is not done during iterative processing of the mock negotiation, but 
after the conclusion of die mock negotiation. To determine if a package is Pareto- 
optimal, all INSS has to do is compare the parties' ratings for the various packages to 
see if any package has higher ratings for both of them. If none of the packages have 
higher ratings for both parties, then the one they agreed on in the mock negotiation is 
Pareto-optimal for them* This is a simple arithmetic function and has nothing to do with 
analysing the issues (terms) or options (values) in the mock negotiation* 

The rejection of applicants' claims in view of INSS further states that INSS processing 
includes: 

"recognizing any changes in the terms ..." . 
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Applicants respectfully disagree again. As applicants believe their above analysis 
shows, there are no ch an ges in the terms to be detected or recog nized bv TNSS. All 
possible term values (issues and options) are specified ahead of time, when the issues 
and options are specified so the case can be built. The players do not enter new issues or 
options during a mock negotiation, they select from packages or the predefined options 
to construct "offers''. 

This is made clear at page 15, under the heading "3.Using INSS", starting at number 6: 

"6. Rate the packages , A number of packages are displayed for you . Pach package has a 
rating. Check if you agree with the ratings. If you disagree with the ratings of any of the 
packages change them in the box on the right-hand side of the table. Please do not try to 
manipulate these rankings as they are used for their own benefit. 

From ribw on evety offer (a package) which you want to consider and present to your 
partner will show a rating based on your preferences* Any offers sent to you by your 
partner will also show a rating. Remember, this rating reflects your and only your 
opinion. Your partner does not know your opinion nor can he or she see your ratings. 

7. Fill out the pre-negotiation questionnaire . 

8. Make an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box/' [Bolding added] 

It appears from this that the players do not enter option values such as $310,000 in an 
offer screen during the mock negotiation. Instead/ as the above excerpt from the INSS 
article says, the INSS simulator presents the players with a menu of the predefined 
packages, from which they select one — such as Package 12, for example, to use as an 
"offer". 

Thus, an "offer" of $31 0,000 and 0 warranty, is not a change in terms or a new term. It is 
one of the packages which was predefined when the case was set up initially. It is also a 
package which each of the players has already rated during the pre-negotiation rating 
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phase. These ratings are presumably also stored in connection with the predefined 
package. This is why it is a simple matter for the INSS system to "present" that offer to 
the other player, and along with it show to the other player that player's (Suny in this 
example) rating for that same predefined package. 

For example, in the aircraft model for the airplane example, predefined Package 9 has a 
rating of 100 for Maki and a rating of 0 for Suny. If Maki "offers" package 9 to Suny, the 
INSS simulator does not have to recognize any changes in order to present Package 9 to 
Suny. There are no changes to Package 9. Nor does INSS have to do any calculation to 
show Suny's pre-supplied rating of 0 for Package 9, as that value has also been 
previously stored. The rating Suny has previously supplied is not based on any changes 
in terms (issues and options), since there can be no changes during a mock negotiation. 

INSS does not have to plug in the correct data into any calculations, since all the data 
for issues, option values, and ratings has been entered before the mock negotiation 
began. Even the Pareto-optimal solution(s) for the players can be determined in 
advance using the ratings supplied by the players. INSS only needs to wait until after 
the mock negotiation has completed to suggest the better solutions. 

It is also a simple matter for INSS to "track" the mock negotiation without analyzing the 
issues or options to understand their purpose or recognizing any changes in the issues 
or options* All it has to do is record in a file that player 1 "offered" predefined 
package 3 at time x, then player 2 "counter-offered" predefined package 4 at time y, 
and so on. 
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It in a simple matter to plot the graphs shown on Page 11, since the graphs are only 
showing the players' predefined ratings for the sequence of packages that were 
"offered". Since the ratings have already been supplied in advance of any mock 
negotiation, they can simply be stored in a table or model. The content of the packages 
does not change during the mock negotiation. 

This is quite clear from each graph. On the y axis or vertical side of the graph are shown 
the possible ratings, and on the x axis, or along the bottom of the graph are shown the 
dates when "offers" were exchanged- The two lines in each graph represent the "offers" 
from each party. The graph on the left shows the player Maki's {Misty's?} ratings for 
both sets* The graph on the right is different for the other player because it shows the 
sets of "offers" as they were rated by that player. 

Since all of the "offers" which are rated and have their ratings graphed in the article 
were based on predefined packages, the graphs do not show any changes in terms, 
because there is no way for a player to change terms during a mock negotiation . Maki's 
rating for Package 9 will always be 100, when that package is offered to Maki, no matter 
when it is offered. Similarly/ Suny's rating for Package 9 will always be 0 when that 
package is offered to Suny, no matter when the package is offered. 

What the players are doing when they use the INSS simulator is presenting offers of 
predefined issue and option data, as described above. It should be noted that while the 
primary method INSS describes for selecting these predefined issues and options uses 
what it calls parallel negotiations in which the players select from complete packages to 
prejsent an "offer", the INSS article describes on Page 3, an implementation of what it 
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calls Sequential negotiations, in which the players can select from a subset of predefined 
issues and options, so that a complete package does not need to be selected. That 
presumably, is why the players are also asked to rate the issues and their options 
separately as well as the different packages. In any case, there are still no changes in 
texins, Since all the issues and options and ratings must still be predefined before the 
mock negotiation can begin. 

Applicants believe that a few lines in the article create the confusion on this point On 
Page 3 of the INSS article, it states that INSS has a list of 9 options under the heading 
"Negotiation Protocol/ 7 The list is preceded by a paragraph which states that "At 
present INSS allows to construct a protocol from three options listed below/' In that 
list, Option 5 is "New values for continuous issues and Option 6 is New values for 
discrete and ordered issues and item 7 is New issues. 

Directly below this, the article states under the heading "How to choose?" : 

"Because the additional options listed above are not yet implemented you don't need to 
choose any specific protocol now. The three options already implemented provide you 
with additional flexibility in conducting negotiations/' 

These seem to suggest that users might be able to enter new values for issues under 
options 5 and 6. However, this also seems to say that only the first three options are 
implemented -not options 5, 6 and 7. However, even if they are deemed to have been 
implemented Applicants do not believe they change the above analysis. 

For example, in the discussion of " New values for continuous issues' 7 the INSS article 
states; 
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"This Option will allow to enter any value for a continuous issue other than the values 
specified at the beginning of negotiations. The continuues {sic} issue {sic} are thosetor 
which ifttermecUate valuls make sense. Price for example, is a continuous issue. The 
initial values maybe $10, 420{sic} and $30. The option allows users to enter value {sic} 
of, for example, $15 which initialy {sic} had not been an option. 

Here we will also allow quasi-continuos {sic} issues which are naturally ordered but for 
which ratios or some other numbers make no sense. For example, such an issue is the 
project completion time or product delivery time. It does not make sense to talk about 
delivery time of 1 .75 days. However, we wUl leave this problem to the users and 
assume that they will select numbers that make sense in their negotiations. 

An important problem that has to be mentioned here is the approximation of tiie 

utii ity .Tho utility funrHnn that is d »*»mmrigd durinr the pre-negoharion phase has to be 

inter polated with new op flp™ being specified." 

[Emphasis added] 

Whileat first blush this might seem to suggest that a player can enter a new value 
during a mock negotiation, the last sentence makes it doubtful exactly what occurs. 

First, for continuous issues, a "new value" must be an intermediate value— i.e. in the 
range of the previously defined values. If it is not an intermediate value, then all the 
ratings would have to be redone, in a pre-negotiation step. Recall that in the discussion 
of ratings, for each option supplied for an issue, one must be given the maximum value 
and one must be given a value of 0. Thus, if the ratings are to be useful at all, the only 
way a "new value" can be included for a continuous variable is if the new value is an 
intermediate value already in the range of the values which have been rated. This 
seems dear from the point made in the sentence "An important problem that has to be 
mentioned here is the approximation of the utility. The utility function that is 
determined during the pre-negotiation phase has to be interpolated with new options 
being specified ." 
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The utility function (rating) that has been supplied for this issue and its previous 
options (values) has to be "interpolated" according to the above. Interpolation, as 
defined in Webster's New World dictionary, item 3 Math, means "to estimate (a 
missing functional value) by taking a weighed average of known functional values at 
neighboring points, as in estimating a specific, missing intermediate value on a table, 
esp. a logarithmic or trigonometric table/' Thus, it would appear that the INSS 
simulator or the NSS software would assign some rating to this intermediate value* 
However, it is not clear when that would be done — from the last sentence quoted it 
appeats that this is done at the pre-negotiation phase. The article is ambiguous on this 
point One way of reading this is that the interpolation might be done during a mock 
negotiation, but that is not what this appears to say. 

Apparently this feature, and the feature described as new values for discrete issues, 
would allow a user to modify an existing negotiation case. But apparently this would 
still have to be done before the mock negotiation occurs as the discussion of the impact 
on utility functions (ratings) makes clear and as the general discussion of the operation 
of INSS in constructing offers makes clear. This apparently is also the reason why a 
"new" continuous value must be an intermediate value (in the example shown, 
somewhere between 10 and 30), since that would also be the only way INSS could 
interpolate a rating for it 

The discussion of new discrete values makes it even clearer that the players must go 

badk to the pre-negotiation stages to enter ratings, as is said at page 5: 

"Since there is no way to caculate |sic} the rating of new values based on the ratings of 
othfer options, the user would be required to enter the rating for any new discrete 
options/' 
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Ratings can only be entered during the pre-negotiation phase. Because of the way in 
which INSS describes how a player selects an offer from pre-packaged sets, it seems 
logical to conclude that options 5 and 6 only allow someone to modify an existing case 
before ianother mock negotiation begins. 

Similarly, option 7, New issues is described on Page 5 as: 
"New issues can be brought to the negotiation table during or even before the 
negotiation begins. This allows INSS users to make their own negotiation case online or 
extend greatly their current negotiation/' The only description of how this might be 
implemented, if it was ever implemented, has already been covered above in the 
discussion of creating a new case. A new case can be created by predefining all the 
issues and options ahead of time, as described on page 6 of the INSS reference, the very 
next page after this discussion. 

Another paragraph in the article which seems to suggest more than it actually offers 
occurs on Page 2, under the heading "4. Negotiation support system": 

"INSS san also act as an NSS and support and facilitate real-life negotiations. The 

system is designed so that two parties who can agree on the issues and the possible 
options for those issues c an negotiate over the Web, This is an obvious advantage when 
the parties are widely separated and may have difficulty arranging meetings. Using 
INSS is also helpful when post-settlement improvement is likely /'[Underlining 
emphasis added.] 

Again, at first blush, this seems to offer more scope for INSS, but it is only helpful if the 
"two parties can agree on the issues and the possible options for those issues/' In INSS 
tertns, this means the parties must create a new negotiation case which predefines all 
theivalues for the issues and options, as discussed above* Those familiar with real life 
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negotiations realize that it is unlikely that this will occur — most of a real world 
negotiation is about the value to be assigned to an issue as a negotiation progresses 
through a series of iterations. 

In any case, if the parties were to agree to a predefined set of values for the issues and 
options, the INSS system would still only be able to provide NSS support — that is, 
perfotsh the Pareto-optimal determination based on the parties' ratings and perhaps 
suggest better packages. This might be helpful, but it is not a negotiations system. It is 
using a simulator for providing a negotiation support system function/ not analyzing 
terms to understand their purpose or recognizing changes in terms. The authors of the 
INSS article dearly recognize this when they preface this discussion by saying that INSS 
can act as an NSS and su pport and facilitate (but not process) real-life negotiations. 



While it might be argued that simulators may sometimes anticipate functionality for 
purposes of patentability, applicants submit that in computer hardware and software 
development, simulation tools have long been used to feign functionality that is still 
under development If a manufacturer is developing a new operating system and new 
computer hardware at the same time, it is common for developers to use simulation 
tools to mimic functionality yet to be developed* The real operating system may be 
interfaced to a simulation model that pretends to operate as the hardware should, even 
if tihe hardware developers do not yet know how to implement the hardware. The 
operating system may pass a value to the simulation tool, which "pretends" to operate 
on;it, but simply returns to the operating system a pre-programmed answer for that 
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value. The simulation tool could be said to be performing the same functionality as the 
a$ : yet undeveloped hardware, without necessarily anticipating the later hardware 
features actually developed. 

In any event applicants respectfully submit that it has now been shown that INSS does 
not perform the same functionality recited in Applicants' claimed invention and does 
not anticipate, disclose, teach, nor render obvious Applicants' invention. The authors of 
the INSS paper do not describe it as a negotiation system. They are quite clear that it can 
be used as a game, a demonstration decision support system, a negotiation simulator, a 
demonstration negotiation support system or a research and training tool but they do 
not disclose or describe it as a negotiation system. 

Thte descriptions of how to create a case in order to use the simulator make it clear that 
all the possible values and issues must be identified/ specified, and predefined before a 
negotiation can be simulated. Since all the issues and options are defined in advance, 
the INSS software does not analyze terms to understand their purpose, nor does it 
recognizes changes in terms- It can only deal with pre-programmed issues and options. 

The description on Page 15 of how "offers " are constructed from the predefined/ pre- 
rated packages, makes it dear that the players do not change any terms (issues and 
option$) during their mock negotiation. They "offer" the predefined packages or 
subsets of them to each other until they reach an "agreement" in their mock negotiation. 
Sinice there are no changes in the terms during such a mock negotiation, the INSS 
system cannot recognize changes. 



Paw 37 of 44 



PAGE 39/46 * RCVD AT 3/27/2006 9:40:57 PM [Eastern Standard Time] * SVR:USPTO£FXRF-5/18 * DNIS:2738300 " CSID:508 653 8143 * DURATION (mm-ss):12-28 



Sent By: MAUREEN STRETCH; 



508 653 8143 ; Mar-27-06 9:59PM; Page 



Docket Number ETO0-001CIP PATENTS 

The rejection also stated that, INSS recognizes which party is officially waiting for a 
response, thereby recognizing a relative "deciding entity/ See page 17, item 5 in 
particular/' 

Applicants respectfully disagree. First applicants can find no instance in the article 
which states that INSS recognizes which party is officially waiting for a response. 



In fact, it would seem that the opposite is true — the INSS system is indifferent to which 
party to a mock negotiation is "officially" waiting for a response. At Page, 14, under 
the heading "1- Introduction" it states: 

"Participants in the negotiation are paired randomly and anonymously. Your partner 
may b^ from your city, country or from far away: a different country, a different 
continent Please log in at lest once in two days to check whether there has been any 
activity. If you have provided an e-mail address, INSS will send you a note when your 
counterpart makes an offer, but it is better not to rely on these e-mails; do log in 
frequently/' 

Also, on Page 15, under the heading "3.Using INSS", it states: 

"8.; Make an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box. 

9. You will then have to wait for your partner to respond to your offer. Come back later 
(say the next day) and login to INSS using the same negotiation name, user-name and 
password. INSS will show you whether your partner has sent you a response- Keep 
checking till you get a response* If vou like, you can continue to send messages or new 
offers to v our partner / 7 [Underlining emphasis added J 



Arid the section cited in the rejection at Page 17, item 5 reads: 

"5.: I hatve sent an offer and my counterpart has not yet responded to it. INSS shows 
me a Waiting for response" page. Can I send a second offer instead of waiting? 

Yes, you can make consecutive offers without waiting for your counterpart* Click on the 
''Makfian offer" link in the menubar at the bottom of your page. There is also a link in 
the menubar that allows you to just "Send a message instead of an offer/' 
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None of these suggests that INSS recognizes either player as "officially" waiting for a 
response. Instead/ because these cites suggest that either party can send multiple offers 
to the other without receiving any response, it is clear that there is no "official" waiting 
for response status that would suggest INSS recognizes the one waiting as a relative 
deciding entity. Nor does the ability to send multiple offers make either party a 
deciding entity. 

Applicants respectfully submit that INSS does not recognize either player as a deciding 

entity/ but on the contrary, as is stated on Page 16, it would appear that the INSS 

simulator and NSS functions determine when negotiations are concluded; 

"11. When both you and your partner accept an offer, it is called an i agreement!, {sic} 
INSS will tell you whether your agreement is "optimal", or whether it is possible to 
imjprove it and move towards a better agreement/' 

12.; If INSS says you have reached the end of negotiation, fill out the post-negotiation 
questionnaire. Otherwise you have the choice of making more offers till you reach a 
better agreement or stopping at this point. In any case fill out the questionnaire when 
you reach the end of the negotiation/' [Bolding emphasis added] 

From this, it would seem that neither party is a deciding entity. The INSS simulator 

decides whether a negotiation is ended. 

In summary, INSS as disclosed and described in the article cited does not, in any way, 
perform the functionality of Applicants' claimed invention, nor would it render it 
obvious. INSS is not a negotiations system. INSS does not analyze terms to understand 
thsir purpose, nor docs it recognize changes in terms, nor does it recognize a party as a 
deciding entity. In fact to the extent that INSS requires predefinition of values it 
teaches away from Applicants' invention and relates to older art on simulation tools 
and decision theory, not to Applicants' invention. 
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Consequently, Applicants respectfully submit that this basis for rejection has been 
overcome and that Claims 2-17, 26-41,50, 51, 60-70, 77-B7, and 98 as well as new claims 
99-162;are in condition for Allowance- 
Obviousness under §103: The rejection states that the use of unique identifiers, and 
maintaining records as an audit function would be obvious to one of ordinary skill in 
the art- and would not> by themselves, render the claims patentable in view of INSS. 
Applicants respectfully submit that this is a moot point since the rejection based on §102 
has been overcome. 

Consequently, Applicants respectfully submit that this basis for rejection has been 
overcome and that Claims 2-17, 26-41,50, 51, 60-70, 77-87, and 98 as well as new claims 
99-462 are in condition for Allowance. 

Priority . 

The Examiner refected applicants' priority claim for the instant application, because the 
phrases "dynamic contracts manager" and "security extensions such as access control 
lists, privilege lists, etc/' were not disclosed in the parent applications, such as US 
Patent No. 6,141,653. 

Applicants respectfully disagree. As this application claims, the dynamic contracts 
manager supplies an initial set of terms for use by a user. As stated in the instant 
application at Page 79, this functionality operates in conjunction with the sponsored 
community function of the parent applications. 
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Applicants respectfully submit that support for this functionality is found in the above 
referenced parent application at Col. 17, lines 46-47; 

Thie sponsoring standards body establishes the community, proposes initial standards, 
sets the rules for negotiations, encourages and monitors negotiations, and concludes 
with a finally agreed upon set of standards, with each step of each negotiation that 
occurred along the way archived- [Emphasis added] 

anil again at Col. 20, lines 6-18: 

In a commerce community, the participants might be grouped as sellers 08grpa and 
buyers: 08grpb. Seller participant 08grpa functions include automatically integrated 
remote Web authoring 214-02 and processing and administration 214-04. In remote 
Web authoring 214-02, the present invention allows a seller registering with the 
spfoisofred community, to automatically create a seller's Website within the community, 
onicontpletion of registration. The seller selects from several Website format templates 
pnj>vi4p4 hy the present invention and as the seller "fills in the blanks" in a selected 
template, the information is automatically integrated with the rest of the system, so that 
orders ban be processed and accepted immediatelv ...f Emphasis added] 

and again at Col. 23, lines 61-67: 

In now commercial communities, such as standards communities or treaty negotiation 
communities, a sponsor 06 may wish to designate multiple deciding entities for each 
issue under consideration. In such an implementation, a sponsor 06 will u sually want to 
establish more detailed rules for the ordering and processing of proposals. [Emphasis 
added} 

arid again at Col. 24, lines 45-58; 

While Some users of the present invention may want to install parts of it locally, it is 
another advantage of the present invention that it can also be used for a "one-time" or 
"niarfy instantaneous" community negotiation* Turning briefly to Figure lc, if the 
sp<bnsor of community CB is a standards body, it could create a community Website for 
the ne gotiation of a particular standard, enlist participants, and encourage and monitor 
the negotiations without anyone having to buy or install additional local hardware or 
software. When the negotiation is complete and the concluding agreed upon standards 
document can be made available to all concerned, the community could be 
"dismantled" and the participants could disband without wasting any hardware or 
software installations and expenses. [Emphasis added] 



and again at Col. 27, lines 43-64: 
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In this diagram, it is assumed that a seller is registering for the first time with a 
sponsored commerce community . Other types of communities might vary this 
processing. First at step 400, the seller chooses from one or more templates provided by 
multivariate negotiations engine system 02, based on the level of cost and functionality 
the setter desires. Sample website pages constructed from such templates by a 
hypothetical company named Exports, Inc., are shown in Figures 31a to 31d. 

Next at step 405 in Figtire 4a the seller provides basic information as prompted by the 
systemithrough a setup screen such as that shown in Figures 10-1-10-3. Portions of die 
demographic information collected there, along with other data collected later is 
automatically formatted along with the META tags and Meta Keywords for automatic 
submission to search engines. At step 410 in Figure 4a, the system presents the 
cxattimimity's standard license agreement and terms to the seller . If the seller agrees to 
the terms at decision block 425, processing continues. If the seller does not agree, the 
seller mav proceed to block 420 to negotiate with sponsor or elect not to participate . 
[Emphasis added] 

and at CoL 15, lines 7-12: 

Still another aspect of the present invention is that sponsors can perform many more 
functions, such as establishing stand ards, basic contract terms for the communis (if 
desired), removing non-compliant participants, changing the structure of the seller and 
buyer databases, and so on man existing systems allow any administrator to perform. 
[Emphasis added] 



Applicants believe that the above excerpts provide ample support for a dynamic 
contract manager supplying initial terms for use by a user in the parent applications. 
While Admittedly the exact phrase "dynamic contract manager" is not used in the 
parent applications, this functionality is clearly disclosed in the above excerpts* 



Similarly, applicants believe the parent applications provide ample support for security 
extensions such as access control lists, privilege lists, and so on. Applicants respectfully 
submit that such support can be found in parent US Patent No. 6,141,643 at Col. 20, 
lines 1-4: 
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Note that access to relevant information by each type of community member (sponsor 
buyer, seller) is protected by password security and access levels. 



and again at CoL 20, lines 49-55: 

Rgure lm, shows the external functions 211 of the present invention. Reporting 211-02 
is cine type of external function 211* When participants have concluded a negotiation, 
one or both of them may wish to have the final documents and current status of the deal 
reported back to them. The present invention protects the documents with separate user 
names, passwords and access levels for each inquirer . [Emphasis added] 



and again at CoL 23, lines 24*41: 

Still in Figure Id, the principal functions of the present invention operate as part of 
Webserver software 210s executing in Webserver hardware 210w. Multivariate 
negotiations engine 212 is the central function, with sponsor functions 213, participant 
functions 214, external functions 211 and network functions 207 working in cooperation 
with it.; All of these, in turn, communicate through the IP firewall 2031 to database 
furtctidfcis 222, operating with database server system 220, to maintain database(s) 225. 
Security of sponsor and participants' communications is provided at the Webserver 
level through secured socket layer (SSL) encryption schemes offered by most Webserver 
software products, while an additional layer of security is provided by restricting access 
to database server computers 230, where databases 225 resides, by use of IP firewall 
203f . Thus, the present invention enables the collection and storing of negotiations and 
results data in a highly secure hosting environment over a public network. 

Consequently, Applicants respectfully submit that the instant application be granted 
the priority date claimed. 



Applicants respectfully submit that all bases for rejection have been overcome, that the 
instant application should be granted the priority date claimed and that Claims 2-17, 26- 
41,50, 51, 60-70, 77-87, and 98 as well as new claims 99-162 are in condition for 
allowance. Reconsideration of all the claims is requested. Allowance of Claims 2-17, 26- 
41,50, Si, 60-70, 77-87, and 98 as well as new claims 99-162 at an early date is solicited. 
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Applicants ' Attorney respectfully requests that if she can be of any further assistance in 
putting all the claims in condition for allowance that she be reached by telephone at 
508-653-8143 in order to discuss the application with the Examiner, so that any new 
objections or rejections may be addressed. 

Respedfuliy submitted, 




Maureen Stretch 
Reg. No. 29,447 
26 Charles Street 

Naitickr MA 01760 
3/27/06 
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